Шош, по итогу просмотра, имеем 1. на правило крос импорта в Widgets забили, 2. на правило крос импорта в Entities забили, 3. Features использовали не верно, но потом вроде верно, но может и не верно 4. кастомные подслои ))) самое частое что я слышал в докладе "...опять же методология это запрещает, но мы вот тут столкнулись, и придумали..." я предлагаю свою: 1. создаем папку src/ 2. плохо код не пишем, а пишем хорошо мне кажется, что она даже чуточку получше будет
Самая большая проблема фсд, это субъективщина, каждый в команде понимает по своему. Плюс код размазывается тонким слоем по проекту, совершенно без причины. Если мы что-то переиспользуем, только тогда это надо выносить в энтити или фичу, в остальных же случаев это карго-культ.
Иногда данная субъективщина играет на пользу) в общем то самими разработчиками FSD закладывалось то что каждая команда может подстроить методологию по своему, главное что бы кодеры в контексте одной команды понимали эти пастулаты)
@@yunglocokid1457 "...главное что бы кодеры в контексте одной команды понимали эти пастулаты" тут многовековые баталии идут что лучше react/vue/angular, теперь еще и срач в команде будет что в Entities, а что в Features, и даже когда все устанут и смеряться, придет новый чел из другой компании в которой использовали fsd но другой, и начнется все сначала. Как и любая методология все сводится "пиши код хорошо, плохо не пиши", так что без четких правил это лишь опыт лида натянутый на какие-то правила с исключениями основанными на опыте, уйдет лид, потихоньку наступит трэш) можно было и не создавать сайт под fisting-suka-design
Александр классный докладчик! Просмотрел до конца. Но мне до сих пор не понятно, какие проблемы решает FSD на фронте, что делает проще, легче и быстрей. Ощущение, что этот FSD ради FSD и при этом довольно трудно ему следовать ибо концепция довольно субъективна
Судя по видео, FSD не решает проблемы, а создает их. И докладчик 45 минут объясняет нам, как продолжать ехать на велосипеде после того, как мы сами себе вставили палку в колесо.
Возьмите какое то свое приложение которое вы хорошо знаете. И соберите его по FSD, все вопросы будут закрыты, зачем и почему. Я раньше тоже думал надо ли оно мне. Оказалось что надо.
@@xxxxxxxeeeeeeeeee ну получается это проблема человека который понял тогда, методология то тут причем?) Но я и не спорю, что это какая то серебряная пуля, совсем нет. Мне наоборот проще по старинке работать, и гемороя меньше.
Кстати, неплохой доклад. Я думал он, как адепт ФСД, будет рассказывать как ОЧЕНЬ важно все раскладывать по нужным папочкам, а он практически сразу сказал про то что, ну вот не работает на больших проектах. Свой линтер и настойчивость команды ФСД в упоре на "чистый" ФСД - это не очень хороший сигнал. Вообще, конечно, хорошая идея держать структуру папочек максимально плоской и иметь хоть какую-то конвенцию по их неймингу. Но по мне так ФСД - это чисто русскоязычная тема, за которой не стоит какой-то реальной технологии, а конвенцию папочек я и сам вам придумаю или пойму (если ее писали с капелькой здравого смысла). Я бы не хотел работать в команде с жесткими адептами ФСД.
Я пытаюсь внедрить FSD на всех своих проектах уже как год, но сейчас понимаю, что это оверрейтед методология) Даже в самых базовых случаях приходится нарушать привила (например кросс-импорты). Надо придумывать что-то другое
Че за эпилепсия у монтажера. Докладчик рассказывает новые штуки опираясь на слайд, нам покажут зал, покажут докладчика, покажут взгляд под углом, но не сам слайд 🤦♀️ Некоторые слайды в кадре появляются буквально на 2 секунды, даже прочитать не успеваешь как уже меняются. И это опять же гениальное чувство монтажника.
Что плохого в модульной архитектуре на подобии той, что используется в Ангуляр проектах? FSD по сравнению с ней гораздо сложнее;( В одной крупной компании придумали, все копируют, совершают ошибки, сам FSD частенько конфликтует с другими библиотеками и фреймворками, при чем даже с документацией в ней сложно разобраться и по итогу проект только еще сложнее становится.
тем что даже в ангуляре в модульной архитектуре можно довольно хорошо поговнокодить. fsd ложится хорошо под любую архитектуру будь то react, angular или vue, и вообще никак не конфликтует. В ангуляре не используя никакой методологии, можно наклепать модулей, и все равно иметь зависимости между модулями, потому что некоторые вещи с ростом проекта, как правило, начинают использоваться в нескольких модулях. можно вынести все в shared, тогда будет у тебя вроде как переиспользуемый код с одной стороны, а с другой стороны у этот код будет содержать бизнес логику, а так как еще он используется в разных модулях, наверняка он еще будет меняться под новые какие то требования, а это уже нарушает обычный SOLID. методология FSD совершенствуется, потому что общество растет, вопросов становится больше, и следовательно и ответов на эти вопросы. FSD требует не документацию, а целую книгу, потому что это архитектурная методология. Строгих инструкций тут быть не может. Ты также не найдешь документацию по DDD, нужно прочитать как минимум одну книгу, и поработать с каким то проектом, чтобы понять что да как.
Наговнокодить можно где угодно, и fsd тут не исключение.) А "кривой" концепт fsd, который сами авторы не могут описать в документации, не слабо увеличивают эту вероятность.)
@@SuhushinAS есть телега, есть сообщество, есть бот который поможет ответить на многие вопросы, есть множество примеров... остальное уже в ответственности разраба
@@SuhushinAS здрасьте. тогда давайте поговорим о бэкенде. попробуйте разрабатывать приложение на DDD не прочитав хотя бы одну книгу по DDD. а в отличие от FSD, такой вот официальной документации по DDD вообще нет. А даже прочитав книгу, там появится столько вопросов, что придется еще и доклады разные послушать, и с опытными разрабами проконсультироваться, и т.д. Архитектура вообще по своей сути не углубляется в тонкие детали реализации. Если вы найдете такую волшебную архитектуру и документацию к ней, где все сразу будет понятно и разобрано до мелочей, дайте знать.
Докладчик задел тему про получение моделей от бекенда. Для этого лучше использовать кодген опенапи или графкл, ну или иные инструменты которые для этого подходят. Странно, что не сказал, когда упоминал
На мой взгляд, бесполезный доклад, продающий бесполезную FSD-методологию, которая только в теории звучит хорошо, а на практике создает только проблемы с неудобным "размазыванием" кодовой базы по многим файлам, созданием излишних сущностей, папок, файлов и смысловых противоречий даже в простом проекте. Кому FSD упростил жизнь в боевом проекте? Напишите, пожалуйста, ответ на этот комментарий. Я пробовал FSD и ужаснулся от его бесполезности для решения реальных проблем сложности разработки любых frontend-проектов.
Какая архитектура тогда полезна ? FSD не заставляет вас создавать сущности, по сути только 3 слоя обязательны(app, pages, shared), можно все делать в папке pages, и выносить общие компоненты в shared.
@@BorisEdigarian Любая кастомная модульная архитектура, удобная команде или группе команд. По моему, это очевидно, разве нет? Если, как вы сказали "можно все делать в папке pages, и выносить общие компоненты в shared.", то где тут FSD, подразумевающий наличие Entities, Features и прочие излишние абстракции? В вашем описании не прослеживается какая-либо архитектурная методология, а я спросил про то, кому FSD упростил жизнь в РЕАЛЬНОМ ПРОДЕ.
@@BorisEdigarian app, pages, shared - друг, то что ты описал понимает любой неглупый разработчик на фронте и без FSD коршунов. app, pages, shared - это та база, с которой я уже ни один проект начинал. При чём тут fsd вообще?
Очень слабо, по сравнению с курсом по FSD от Евгения Паромова. Александр, как будто заучил по бумажке перед выступлением. У Ильи же сразу видно - человек сам лично прошел через проблемы по построению архитектуры на фронтенде, где в своём видео всесторонне объясняет тематику.
Уви-юви-юви-юви-ю, оу, уви-юви-юви-юви-ю, оу🤣🤣🤣 Впечатление, что во врот-энде количество мудацких, бессмысленных фич просто запредельное. Сначала пришли фреймворки, потом - фреймворки под фреймворки, бесчисленное количество надстроек над ними. И вот снова какое-то очередное унылое смузихлёбство. Как же хорошо, что пишу на чистой ванили и php, и не надо париться над этой всей дичью.
Это делается специально. Выдумщики потом обосновывают бизнесу, почему они заслуживают большую зарплату и сидеть над челами, которые кодят и думают лучше их. Тыкнул пальцем и сказал: «да яяяя воообще-то новый архитектурный подход придумал!»(организацию папок на самом-то деле)
Шош, по итогу просмотра, имеем
1. на правило крос импорта в Widgets забили,
2. на правило крос импорта в Entities забили,
3. Features использовали не верно, но потом вроде верно, но может и не верно
4. кастомные подслои )))
самое частое что я слышал в докладе "...опять же методология это запрещает, но мы вот тут столкнулись, и придумали..."
я предлагаю свою:
1. создаем папку src/
2. плохо код не пишем, а пишем хорошо
мне кажется, что она даже чуточку получше будет
в сотни раз лучше и понятней объяснён FDS, чем в самой его документации ) спс.
если у каждого свое понимание фсд - то значит есть проблема с методологией.
обратная сторона гибкости
Самая большая проблема фсд, это субъективщина, каждый в команде понимает по своему. Плюс код размазывается тонким слоем по проекту, совершенно без причины. Если мы что-то переиспользуем, только тогда это надо выносить в энтити или фичу, в остальных же случаев это карго-культ.
Иногда данная субъективщина играет на пользу) в общем то самими разработчиками FSD закладывалось то что каждая команда может подстроить методологию по своему, главное что бы кодеры в контексте одной команды понимали эти пастулаты)
@@yunglocokid1457 их нельзя понять, у них нет определения
Так потому что этот фсд буквально наркоман сова выдумал
@@yunglocokid1457 а в чем тогда плюс методологии, если мы опять пришли к тому, что все делают все по своему?
@@yunglocokid1457 "...главное что бы кодеры в контексте одной команды понимали эти пастулаты" тут многовековые баталии идут что лучше react/vue/angular, теперь еще и срач в команде будет что в Entities, а что в Features, и даже когда все устанут и смеряться, придет новый чел из другой компании в которой использовали fsd но другой, и начнется все сначала. Как и любая методология все сводится "пиши код хорошо, плохо не пиши", так что без четких правил это лишь опыт лида натянутый на какие-то правила с исключениями основанными на опыте, уйдет лид, потихоньку наступит трэш) можно было и не создавать сайт под fisting-suka-design
Александр классный докладчик! Просмотрел до конца. Но мне до сих пор не понятно, какие проблемы решает FSD на фронте, что делает проще, легче и быстрей. Ощущение, что этот FSD ради FSD и при этом довольно трудно ему следовать ибо концепция довольно субъективна
Судя по видео, FSD не решает проблемы, а создает их. И докладчик 45 минут объясняет нам, как продолжать ехать на велосипеде после того, как мы сами себе вставили палку в колесо.
Возьмите какое то свое приложение которое вы хорошо знаете. И соберите его по FSD, все вопросы будут закрыты, зачем и почему. Я раньше тоже думал надо ли оно мне. Оказалось что надо.
@@xxxxxxxeeeeeeeeee ну получается это проблема человека который понял тогда, методология то тут причем?) Но я и не спорю, что это какая то серебряная пуля, совсем нет. Мне наоборот проще по старинке работать, и гемороя меньше.
@@lolhohol возьмите готовое блюдо, выбросите его и съешьте говно и все вопросы будут закрыты. Я раньше тоже думал надо ли оно мне. Оказалось что надо.
@@gh8499ничего не понятно, но очень интересно
Кстати, неплохой доклад.
Я думал он, как адепт ФСД, будет рассказывать как ОЧЕНЬ важно все раскладывать по нужным папочкам, а он практически сразу сказал про то что, ну вот не работает на больших проектах.
Свой линтер и настойчивость команды ФСД в упоре на "чистый" ФСД - это не очень хороший сигнал.
Вообще, конечно, хорошая идея держать структуру папочек максимально плоской и иметь хоть какую-то конвенцию по их неймингу. Но по мне так ФСД - это чисто русскоязычная тема, за которой не стоит какой-то реальной технологии, а конвенцию папочек я и сам вам придумаю или пойму (если ее писали с капелькой здравого смысла).
Я бы не хотел работать в команде с жесткими адептами ФСД.
Я пытаюсь внедрить FSD на всех своих проектах уже как год, но сейчас понимаю, что это оверрейтед методология) Даже в самых базовых случаях приходится нарушать привила (например кросс-импорты). Надо придумывать что-то другое
Че за эпилепсия у монтажера.
Докладчик рассказывает новые штуки опираясь на слайд, нам покажут зал, покажут докладчика, покажут взгляд под углом, но не сам слайд 🤦♀️
Некоторые слайды в кадре появляются буквально на 2 секунды, даже прочитать не успеваешь как уже меняются. И это опять же гениальное чувство монтажника.
Прекрасный доклад
Что плохого в модульной архитектуре на подобии той, что используется в Ангуляр проектах? FSD по сравнению с ней гораздо сложнее;( В одной крупной компании придумали, все копируют, совершают ошибки, сам FSD частенько конфликтует с другими библиотеками и фреймворками, при чем даже с документацией в ней сложно разобраться и по итогу проект только еще сложнее становится.
тем что даже в ангуляре в модульной архитектуре можно довольно хорошо поговнокодить. fsd ложится хорошо под любую архитектуру будь то react, angular или vue, и вообще никак не конфликтует. В ангуляре не используя никакой методологии, можно наклепать модулей, и все равно иметь зависимости между модулями, потому что некоторые вещи с ростом проекта, как правило, начинают использоваться в нескольких модулях. можно вынести все в shared, тогда будет у тебя вроде как переиспользуемый код с одной стороны, а с другой стороны у этот код будет содержать бизнес логику, а так как еще он используется в разных модулях, наверняка он еще будет меняться под новые какие то требования, а это уже нарушает обычный SOLID. методология FSD совершенствуется, потому что общество растет, вопросов становится больше, и следовательно и ответов на эти вопросы. FSD требует не документацию, а целую книгу, потому что это архитектурная методология. Строгих инструкций тут быть не может. Ты также не найдешь документацию по DDD, нужно прочитать как минимум одну книгу, и поработать с каким то проектом, чтобы понять что да как.
Наговнокодить можно где угодно, и fsd тут не исключение.) А "кривой" концепт fsd, который сами авторы не могут описать в документации, не слабо увеличивают эту вероятность.)
@@SuhushinAS есть телега, есть сообщество, есть бот который поможет ответить на многие вопросы, есть множество примеров... остальное уже в ответственности разраба
@@valikirr В ответственности разработчика - выбрать архитектуру, которая понятна, без сидения в чатах и имеет все те же преимущества)
@@SuhushinAS здрасьте. тогда давайте поговорим о бэкенде. попробуйте разрабатывать приложение на DDD не прочитав хотя бы одну книгу по DDD. а в отличие от FSD, такой вот официальной документации по DDD вообще нет. А даже прочитав книгу, там появится столько вопросов, что придется еще и доклады разные послушать, и с опытными разрабами проконсультироваться, и т.д. Архитектура вообще по своей сути не углубляется в тонкие детали реализации. Если вы найдете такую волшебную архитектуру и документацию к ней, где все сразу будет понятно и разобрано до мелочей, дайте знать.
Мандец, этот FSD такой запутанный))
Докладчик задел тему про получение моделей от бекенда. Для этого лучше использовать кодген опенапи или графкл, ну или иные инструменты которые для этого подходят. Странно, что не сказал, когда упоминал
А как это относится к теме доклада? Каждый уже сам решает, как он будет этим модельки создавать.
На мой взгляд, бесполезный доклад, продающий бесполезную FSD-методологию, которая только в теории звучит хорошо, а на практике создает только проблемы с неудобным "размазыванием" кодовой базы по многим файлам, созданием излишних сущностей, папок, файлов и смысловых противоречий даже в простом проекте.
Кому FSD упростил жизнь в боевом проекте?
Напишите, пожалуйста, ответ на этот комментарий.
Я пробовал FSD и ужаснулся от его бесполезности для решения реальных проблем сложности разработки любых frontend-проектов.
Такое чувство что люди из бэкенда пытаются писать фронт, и пытаются писать бэк на фронтЕ.
Какая архитектура тогда полезна ? FSD не заставляет вас создавать сущности, по сути только 3 слоя обязательны(app, pages, shared), можно все делать в папке pages, и выносить общие компоненты в shared.
@@BorisEdigarian Любая кастомная модульная архитектура, удобная команде или группе команд.
По моему, это очевидно, разве нет?
Если, как вы сказали "можно все делать в папке pages, и выносить общие компоненты в shared.", то где тут FSD, подразумевающий наличие Entities, Features и прочие излишние абстракции?
В вашем описании не прослеживается какая-либо архитектурная методология, а я спросил про то, кому FSD упростил жизнь в РЕАЛЬНОМ ПРОДЕ.
@@BorisEdigarian app, pages, shared - друг, то что ты описал понимает любой неглупый разработчик на фронте и без FSD коршунов. app, pages, shared - это та база, с которой я уже ни один проект начинал. При чём тут fsd вообще?
FSD модная, но максимально бездарная архитектура. Не используйте ее.
Очень слабо, по сравнению с курсом по FSD от Евгения Паромова. Александр, как будто заучил по бумажке перед выступлением. У Ильи же сразу видно - человек сам лично прошел через проблемы по построению архитектуры на фронтенде, где в своём видео всесторонне объясняет тематику.
Уви-юви-юви-юви-ю, оу, уви-юви-юви-юви-ю, оу🤣🤣🤣
Впечатление, что во врот-энде количество мудацких, бессмысленных фич просто запредельное. Сначала пришли фреймворки, потом - фреймворки под фреймворки, бесчисленное количество надстроек над ними. И вот снова какое-то очередное унылое смузихлёбство. Как же хорошо, что пишу на чистой ванили и php, и не надо париться над этой всей дичью.
Это делается специально. Выдумщики потом обосновывают бизнесу, почему они заслуживают большую зарплату и сидеть над челами, которые кодят и думают лучше их. Тыкнул пальцем и сказал: «да яяяя воообще-то новый архитектурный подход придумал!»(организацию папок на самом-то деле)
+
для одностраничника ОК
Вижу FSD - ставлю дизлайк. Сори, в узбекской архитектуре адекватным людям нечего ловить.
А, это ваши люди наезжают на прохожих (и на меня тоже) на тротуарах?! Уже минус